These messages are generated and transmitted within data communication networks, such as the internet. The architecture of the internet protocols is based on four logic layers, i.e. application, transport, network, and link.
The SNMP messages perform a simple communication mechanism between a Network Manager System (NMS) and the nodes being managed. This is made possible through specific applications located respectively at the NMS called “Network Manager” and at the nodes called “agents”. The SNMP messages therefore take place at the UDP level, using it as a transport for such a purpose.
The application called “agent” (hereinafter: agent) with its respective network manager over the SNMP messages has associated a database currently called “Management Information Base” or, short, MIB. Within such a database, the information is collected relating to the management and monitoring of the corresponding node or network element. In particular such information includes the following:                MIB variables, that may be read by the Network Manager to derive information about the network element;        MIB variables that may be written by the Network Manager to cause actions on the network element; and        events (traps) that the same agent may cause toward the Network Manager (manager) with respect to specific situations.        
The communication at SNMP level essentially includes therefore:                messages required to read/write the above variables (GetRequest, GetNextRequest, SetRequest, GetBulk), sent out by the Network Manager, and        response messages (GetResponse) and trap messages, transmitted by the agent.        
The set of all the variables/traps managed by an agent are bound to the network element and specifically represent the relating MIB, i.e. they show the operation mode and the intrinsic characteristics of the network element to the Network Manager.
Each variable or trap is individually identified by a string in the ASN.1 notation (Abstract Syntax Notation One), called Object IDentifier or OID.
The framework of the string is, for instance, of “1.3.6.1.2.1.4.21” type, indicative of the fact that ASN.1 notation allows the representation of objects according to a hierarchical tree structure.
A part of the MIB has been defined as a standard and is supported by any agent, whereas other variables and some traps are specific for each manufacturer and in some cases also characteristic of a particular apparatus typology.
The SNMP protocol, born in 1988, has undergone some evolutions during the years. In particular new messages typologies have been defined which the agents must be able to understand. The MIB standard, that each agent must be able to support, has been extended. On the filing date of this application, the versions being used are the 1st and the 2nd versions, whereas the standardization of version 3 is currently under way.
The size of a MIB varies according to the apparatus type and can even be of the order of some hundred kBytes, corresponding to some hundred OIDs.
The diagram in FIG. 1 of the attached drawings shows the typical components of an SNMP message. The content of each component is written in ASCII characters and its maximum permissible size is equal to the maximum size of an UDP message, the data entity that carries it, equal to 65,507 bytes or octets (of which about 64 kbytes are designed for the information to be carried).
In particular, in the same diagram of FIG. 1 the presence may be noticed of a message header and of a PDU (Protocol Data Unit) part, of which the part denoted by 1 collects messages such as GetRequest, GetNextRequest, SetRequest and GetResponse, the part denoted by 2 collects GetBulk messages, whereas the part denoted by 3 generally concerns trap type messages.
More specifically, in the header of SNMP messages the following information is present:                Version Number: number of the SNMP version used for message composition (V1, V2, V3, . . . ), and        Community Name: a kind of password that allows access through reading and writing to the objects contained in the MIB module.        
The following information is available within the PDU                PDU type: message typology that in the version 1 contains instructions such as GetRequest, GetNextRequest, SetRequest and Request, whereas version 2 may also contain instructions such as GetBulkRequest and InformRequest;        Request id: individual identifier of the message assigned by the manager and utilised by the agent when answering, in order that the manager might associate the requested response with the appropriate reference;        Error status: set to 0 in all message typologies, except for the response messages, wherein, if set to 1, it means that an error is present;        Error Index: it indicates which one among the requested variables (OID) has caused the error, and—Variable Bindings: these are OID/value pairs; the values are “null” in the case of requests, and compiled in the case of response messages.        
In particular, the part just on the left side of FIG. 1 shows a typical structure of the part collecting the above Variable Bindings.
In the present invention and in the captions appearing in some figures of the appended drawings, the choice has been made of mentioning—for the different elements being considered—the corresponding acronyms/names/initials in the English language.
This has been done for the sake of a clear and straightforward description. The above acronyms, names and initials are currently used at international level by those skilled in the art, since no translations into the different national languages have been developed during the years.
The transmission of the SNMP message, made possible over UDP, allows the data packet exchange between two computers linked to the network. The UDP message format namely consists of a header whose main data are the IP address of the computer transmitting the message, the IP address of the destination computer and the size of the PDU being transported. In turn, the PDU format is formed by a header part and by a data part currently called “Payload” or “Octet Data”. The header therefore contains the following data: source port, destination port, size of the transported unit, integrity check (CHECKSUM) of the data unit.
The methodology currently adopted for transferring a SNMP messages over UDP (from the manager to the agent, and vice-versa) is based in essence on the fact that the complete SNMP message is coded by means of the BER (Basic Encoding Rules) methodology. This way of operating allows one to convert the bytes forming the SNMP message into a hexadecimal structure suitable to be used as a payload of the UDP message.
The UDP transfer service of the data thus obtained essentially envisages:                at the transmission stage: reading of the SNMP message and subsequent hexadecimal coding (BER encode) of the message, for its transmission over UDP, and        at the reception stage: after the reception over UDP, the hexadecimal decoding (BER decode) of the PDU and the subsequent reconstruction of the message.        
The current application practice proves that in the data communication networks such as internet, the need arises of transferring a bulk of information in terms of requests/responses conveyed in the form of SNMP messages.
Owing to the total size of the information, the time required for the relating transfer and network traffic thus generated, the solutions conventionally adopted for transferring SNMP messages in a standard format generally exhibit a rather poor efficiency.
For this reason three IEFT specifications have already been proposed-at a draft level-to tackle the issue.
The first proposal (known as SNMP Object Identifier Compression, rev. April 2001—draft-ietf-eos-oidcompression-00.txt) is based on the concept that the majority of the information' contained in the MIB is referred to by OID, formed by a constant and rather large part and by a variable and very small part. Starting from this principle, the proposal aim is the encoding, according to an algorithm, of the constant part of the OID through a shorter numbering. This solution optimises only in part the quantity of information being transferred, without considerably reducing its size.
The second proposal (known as “Efficient Transfer of Bulk SNMP Data, rev. April 2001—draft-ietf-eos-snmpbulk-00.txt”) faces the issue of the management of the GetBulk instruction that allows the simultaneous collection of a given set of information. The instruction introduced in the SNMP version 2 does not allow the optimisation of the collection, since the manager has to declare the number of elements to be collected, without knowing how many elements form the set of information requested. Amendments to the UDP protocols have been suggested with a modification of the encode algorithm of the message (from BER to PER, which stands for Packet Encoding Rules) or with resort to a transfer mode of FTP (acronym of File Transfer Protocol) type. The solution described in the above cited document, is the introduction of a new instruction at the agent side, called GetColsRequest, and of relating message at manager side, capable of recognising the number of elements to be transferred, identifying the end of the requested set and optimising therefore requests and network traffic. However, also this solution does not allow one to optmise the management of sizes and number of messages being sent.
The third solution taken into account (known as “SNMP Payload Compression-rev. April 2001—draft-irtf-nmrg-snmp-compression-01.txt”) is in principle similar to the first proposal, since it suggests a differential encoding algorithm called “OID Delta Compression” or ODC. Starting from an OID root, such a solution envisages to memorise the subsequent OID assigning to the OID a code associated to the OID root, followed by the varying part of OID. Substantially, the variations are stored in terms of differential increments, as compared to the root element. This solution has the drawback of being incompatible with previous versions of the protocol.
Further, it allows an estimated saving by about 30% for particularly recursive OID values, i.e. data arrays, and it is substantially inefficient in the event of a low number of recursive items.